1. Field of the Invention
This invention relates in general to data processing structures and techniques, and in particular to data processing techniques used with particular computer systems, such as the IBM AS/400 minicomputer, which are required to process task requests from an application in series, waiting for a response from one such task before beginning a second such task.
2. Description of the Prior Art
There is presently a large installed base of IBM minicomputers, particularly the AS/400 series, which are presently limited in their usefulness by their inability to provide a threaded environment for use by application programs. A threaded environment, for the purposes of the present invention, is one in which a plurality of computer programs--such as data collection program or subtask A and data collection program or subtask B--can conveniently perform work for the same user application in paralell, that is, at the same time.
In the AS/400 series, for example, application programs must wait only on one job at a time. That is, a user application such as a computer network monitoring system may be required to schedule work on subtask A to collect data and schedule work on subtask B to collect additional data. This set of operations may conveniently be implemented on a conventional IBM AS/400 operating platform by first scheduling the data collection task on batch job A performing data collection subtask A and then, after the data is collected and returned by batch job A, scheduling the additional data collection task on batch job B. When the additional collection data is then made available to the user application, additional tasks may be scheduled and performed.
The described operations are said to be synchronous in that the batch jobs cannot interrupt other operations of the user application whenever convenient, but rather the user application waits for the results of the subtask or batch job to be presented to it before going on to perform other tasks. This identifies the major drawback to the non-threaded environment operations of the AS/400 because the user application must wait for the results of each batch job before proceeding to the next. In particular, the user application is not able to perform other tasks while batch job A is operating or while batch job B is operating. Similarly, since a user application must wait on one batch job before initiating another, batch job B cannot be operating while the user application is waiting for batch job A to be completed. The resultant waste of time that could otherwise be utilized if such tasks could be operated in parallel is substantial.
Other operating systems utilize a parallel task approach in which subtasks A and B are handled in parallel by different application threads both of which are able to communicate asynchronously with the user application that called them. That is, in a threaded environment the user application would be able to schedule work to be done by application thread A performing subtask A and then, without waiting for completion of subtask A, schedule work to be done by application B performing subtask B. Both application threads are able to communicate asynchronously with the calling user application so that subtasks A and B are performed in parallel while the user application may be otherwise occupied. When either application thread A or B has data available, it communicates with the user application by asynchronous interrupt so that the user application does not have to wait for the data before continuing.
In a situation in which the data from subtask A is required for the performance of subtask B, the lack of a threaded environment for the IBM AS/400 does not cause any substantial inefficiency because there would be no advantage to beginning the performance of subtask B until subtask A was completed. In such a situation, the restriction that the user application can only wait on one subtask at a time is not a substantial detriment. In most complex user applications, there are many subtasks that may advantageously be performed in parallel so that a threaded enhancement for the AS/400 would be extremely valuable.
In an attempt to provide at least some of the benefits of a threaded environment, a polling technique has been used in which the requester does not literally have to wait on only one subtask at a time. In a polling configuration, the user application communicates with batch job A requesting that data collection subtask A be performed. Instead of waiting on batch job A, the user application then communicates with batch job B requesting that data manipulation subtask B be performed. Several additional communications for task requests may also be performed if appropriate. As a result of the fact that a user application in the AS/400 environment may only wait on one batch job at a time, the user application would then normally have to wait on one such batch job until completed.
Using polling however, the user application then iteratively interrogates, or polls, each of the subtasks in some predetermined order to determine if that subtask has been completed. If a completed subtask is identified during polling, and a data transfer is required as a result of such completion, the data transfer may be accomplished or at least scheduled. Although this polling technique, in which the user application is responsible for checking with the subtasks to determine completion, is still a synchronous technique--the communications are controlled by the user application allowing subtasks to be performed in parallel which is an improvement in many situations over the more basic technique in which the user application has to wait for the synchronous communication from each subtask before proceeding to the next subtask.
Many limitations are still encountered with polling techniques, compared to the more optimal asynchronous techniques using threads in which the subtasks retain the responsibility for communicating completion information to the user application. One easy to describe limitation is that completion of a particular subtask cannot be communicated out of turn in a polling system. That is, even though a subtask has been completed and that completion could have been communicated to the user application in a threaded environment, the subtask does not have control of the timing of the completion communication and must wait until it reaches its turn during sequential polling. Additionally, application A must waste CPU resources caused by the polling which robs resources from other AS/400 tasks.
Although the AS/400 is capable of asynchronous operation in that individual user applications and batch jobs may operate in parallel as long as communications between them is not required, the substantial and fundamental modifications that would be necessary to add threaded environment capabilities to the AS/400 operating system would not be practical to implement except by IBM because of the substantial amount of software background information, that is code, which is maintained proprietary to IBM. Such modifications would probably be tantamount to a rewrite and replacement of the AS/400 operating system. Although IBM is believed to have attempted such modification, techniques for operating the AS/400 in a threaded environment are not presently publicly available.
What are needed are techniques for adding asynchronous, threaded environment abilities to the AS/400 that are compatible with the existing installed base of such computers.